A conventional business software application accesses data from disparate data sources. These data sources may include different types of relational database management systems (RDBMSs), legacy software systems, and/or other software systems. Ideally, differences between the data sources are transparent to the business software application. In other words, to provide simplicity and efficiency, mechanisms are provided to enable the business software application to access each data source in an identical manner.
A software application typically accesses stored data by calling some type of middleware. This middleware, in turn, interacts with a connection server which is in communication with any number of different data sources. More particularly, the connection server provides a common Application Programming Interface which is accessed by the middleware to access data of the different data sources.
FIG. 1 is a block diagram of system 100 illustrating such a conventional arrangement. Business Intelligence module 110 (e.g., BusinessObjects XI), for example, requests data from BusinessObjects cube 120. Cube 120 creates a query using query technique 130 and sends the query to data source 140 through connection server 150.
Data source 140 is a relational data source (e.g., a RDBMS) which supports structured query language (i.e., SQL) queries. However, the particularities of the SQL supported by data source 140 may differ from the particularities of the SQL supported by another data source. As an example, some data sources support <<case sensitive>> SQL and some do not.
Since the engine of query technique 130 is generic, regardless of the data source, the system 100 requires configuration information to address differences in the data sources such as that described above. Query language parameter file 160 may address such differences by describing particularities of the SQL supported by data source 140. Parameter file 160 is typically and primarily composed of three parts: parameters which describe SQL syntax particularities (e.g., case sensitive, SORT BY syntax); available operators (e.g., addition, subtraction); and different kinds of supported functions (e.g., CONCAT, COUNT). Connection server 150 may therefore use the information of parameter file 160 to generate queries which conform to the particularities of the SQL supported by data source 140.
A new parameter file is required for each new data source to be added to system 100. Conventionally, this file is manually created by analyzing documentation to determine whether the data source supports each parameter, operator and function, and by manually testing the data source to see how each parameter, operator and function is supported. Many workdays are required to write and suitably test such a parameter file, and the process is repeated for each new data source to be supported.
Systems to efficiently generate a query language parameter file are therefore desired.